This invention generally relates to imaging systems used in medical diagnostics. In particular, the invention relates to the transfer of digital images from an ultrasound imaging system over a network to remote devices for archiving and/or printing.
Conventional ultrasound imagers create two-dimensional images of biological tissue by scanning a focused ultrasound beam in a scan plane and for each transmitted beam, detecting the ultrasound wave energy returned along a respective scan line in the scan plane. A single scan line (or small localized group of scan lines) is acquired by transmitting focused ultrasound energy at a point, and then receiving the reflected energy over time. The focused transmit energy is referred to as a transmit beam. During the time after transmit, one or more receive beamformers coherently sum the energy received by each channel, with dynamically changing phase rotation or delays, to produce peak sensitivity along the desired scan lines at ranges proportional to the elapsed time. The resulting focused sensitivity pattern is referred to as a receive beam. A scan line""s resolution is a result of the directivity of the associated transmit and receive beam pair.
A B-mode ultrasound image is composed of multiple image scan lines. The brightness of a pixel on the display screen is based on the intensity of the echo returned from the biological tissue being scanned. The outputs of the receive beam former channels are coherently summed to form a respective pixel intensity value for each sample volume in the object region or volume of interest. These pixel intensity values are log-compressed, scan-converted and then displayed as a B-mode image of the anatomy being scanned.
If the ultrasound probe is swept over an area of body, a succession of image frames (corresponding to spaced slices intersecting the body being examined) can be displayed on the monitor. In one type of ultrasound imaging system, a long sequence of the most recent images are stored and continuously updated automatically in a cine memory on a first-in, first-out basis. The cine memory is like a circular image buffer that runs in the background, capturing image data that is displayed in real time to the user. The cine memory acts as a buffer for transfer of images to digital archival devices via the host computer. When the user freezes the system (by operation of an appropriate device on an operator interface), the user has the capability to view image data previously captured in cine memory. The image loop stored in cine memory can be reviewed on the display monitor via trackball control incorporated in the operator interface, and a section of the image loop can be selected for hard disk storage.
If the transducer probe was moving during image acquisition, the succession of image frames stored in cine memory form a three-dimensional data volume of image information. This data volume can be used by the system computer to project a three-dimensional view of the area of interest. This projected image can be returned to memory and then displayed on the monitor. Any acquired or projected image can be stored internally on the system hard disk or on a magneto-optical disk (MOD) inserted in a disk drive.
In addition to storing images internally, modern ultrasound imaging systems need to be able to transfer images to various types of remote devices via a communications network. To successfully transfer images, the relevant networking features of the ultrasound imager must be compatible with the networking features of the destination remote device. In particular, the ultrasound imager must place the data to be transferred in a format which can be handled by the destination remote device. An attempt to accomplish the foregoing is the adoption of the DICOM (Digital Imaging and Communications in Medicine) standards, which specify the conformance requirements for the relevant networking features. The DICOM standards are intended for use in communicating medical digital images among printers, workstations, acquisition modules (such as an ultrasound imaging system) and file servers. The acquisition module is programmed to transfer data in a format which complies with the DICOM standards, while the receiving device is programmed to receive data which has been formatted in compliance with those same DICOM standards.
DICOM involves more than digital image transfer. DICOM functionality includes the following Service Classes: archive/transfer images: store (across network); archive/interchange images: media storage; query for information and retrieve images; make image hard copies: print management; patient, study and results management; radiology information system modality: worklist management; and test connectivity: verification. A fundamental concept employed in DICOM is xe2x80x9cServices on Objectsxe2x80x9d. One example of an xe2x80x9cObjectxe2x80x9d is an ultrasound image. Two examples of a xe2x80x9cServicexe2x80x9d are the xe2x80x9cStorexe2x80x9d and xe2x80x9cQuery/Retrievexe2x80x9d functions. In DICOM, methods of operating on information objects are referred to as xe2x80x9cService Object Pair Classesxe2x80x9d (SOP Classes). Examples of SOP Classes are xe2x80x9cStore an ultrasound imagexe2x80x9d, xe2x80x9cPrint an ultrasound imagexe2x80x9d, xe2x80x9cFind which studies there are for a certain patientxe2x80x9d, xe2x80x9cRetrieve all studies of a certain patientxe2x80x9d and xe2x80x9cRetrieve a worklistxe2x80x9d. Unique Identifiers (UIDS) are defined for all SOP Classes. UIDs are also given to all studies, series and images. These UIDs are, for instance, used for retrieval. In the DICOM vernacular, a patient has a study which comprises a study component, e.g., examination using a particular modality. Images acquired in sequence in the course of a study on a patient form a series of objects.
The DICOM system is based on the client/server concept. The device which uses a service (on objects) is the client device, while the device which provides the service is the server device. The client device is referred to as a Service Class User (SCU), while the server device is referred to as a Service Class Provider (SCP). The SCU sends a Service Request to the SCP over a local area network (LAN). The SCP sends back a response to the SCU over the same LAN. If the response is affirmative and a communications syntax is agreed upon, an association between the SCU and the SCP is opened and data can be transferred between the two devices. In the DICOM system a device is not limited to one role: it can be both SCU and SCP at different times.
The DICOM system is designed to facilitate the communication of digital images of different types, e.g., X-ray, computerized tomography, magnetic resonance and ultrasound imaging. In an ultrasound imager having conventional DICOM capability, three local real-world activities occur: Image Send, Image Print and Remote Verification. Image Send and Image Print can be done in either automatic or manual mode. Verification of remote DICOM devices configured on the ultrasound imager is performed when the imager is powered up or when requested by the system operator.
All DICOM activities are handled in a queued manner by application software running on a host computer incorporated in the imager. In one type of ultrasound imager, the user can select any image in cine memory to be sent in DICOM format via a LAN to a remote device having DICOM capability. The host computer of the ultrasound imaging system is programmed with DICOM system software which facilitates transmission of image frames from the cine memory to the remote DICOM device via the host computer hard disk and the LAN.
In the conventional ultrasound imager, Image Send can be used in automatic or manual mode, depending on the user configuration. When automatic mode is configured, console keys are used to capture the image and to store it on the hard disk. The request is queued to a DICOM queue manager (preferably implemented in software), which requests an association with the destination remote device. After the association with the remote device has been opened, the queue manager xe2x80x9cpushesxe2x80x9d the image to the remote device without user intervention. The transfer is done in the background while scanning or other operator activities continue. In manual mode, the captured images are archived on the hard disk or on a MOD during the exam(s). Upon completion of the exam(s) the images are tagged using an archive menu and queued to any of the network devices that have been configured on the imager. The images are sent sequentially in the background while scanning or other operator activities proceed. Image Print works much the same way as Image Send, in both automatic and manual modes, the only difference being that the destination device is a printer.
In order to accomplish image transfer, the ultrasound imaging system must know the configuration of the destination remote device prior to attempting to communicate with that device. The configuration data for the destination remote device is typically inputted to the ultrasound imager during software installation by a field engineer, although the DICOM network can be configured at any time. When the imager receives an instruction to transmit data to a particular remote device from the system operator, the imager software converts the image data to be transferred into the DICOM format required by the destination remote device, based on the configuration data for that device stored in system memory. The imager also sends a request over the network to the destination remote device to open an association, i.e., to connect the imager to the destination remote device. If the remote device responds in the affirmative, the imager and remote device then agree on which SOP Class is to be used and which device will act as the server and which as the client. The ultrasound imager also selects the appropriate encoding syntax from those accepted by the remote device. Other communication parameters are also negotiated.
After the DICOM communications protocol has been settled, the association is opened and the imager attempts to send the DICOM-formatted image file (object) to the remote device via the network. The transfer is done in the background while scanning or other operator activities continue. If the remote device is a storage device, each image file is transferred singly in response to a Send request inputted by the operator. The conventional imager with DICOM capability will open an association with a storage device in response to each xe2x80x9csend to a storage devicexe2x80x9d instruction. If a transfer is successful, the association for that transfer is immediately closed. If the remote device is a printer configured to print multi-image film, then a number of images are accumulated to make up a multi-image film and an association is opened in response to a Send instruction when a number of images sufficient to fill the multi-image film have been accumulated. After the full film session of images has been transmitted, the association between the imager and printer is closed.
If the destination remote device sends back a message indicating successful receipt of the transmitted data, the DICOM-formatted image file can be deleted from the imager memory. Alternatively, the system operator can instruct the imager to retain the DICOM-formatted image file on the imager hard disk or to store it on a MOD inserted in the imager.
The remote device to which the ultrasound imager sends data can be a printer, a storage device or other device. If the operator interface of the imager has only one configurable Print/Store button, then that button will be configured to initiate data transfer to the destination remote device. The configuration data for the remote device will indicate the type of device to the imager and then the imager will format the data being transferred accordingly. If the operator interface has multiple Print/Store buttons, then each button can be configured to initiate data transfer to a respective remote device. Data transfer to any one of those configured remote devices can then be initiated by pressing the appropriate Print/Store button.
In addition to the digitized image (i.e., pixel data), the DICOM object transferred from the ultrasound imager also includes attribute information. For example, the attribute information may include patient attributes (e.g., patient name and patient identification number), study attributes (e.g., accession number and study date), series attributes (e.g., modality type and series date), and image attributes (e.g., image type and numbers of rows and columns). Each attribute has a name, a value representation and a tag. A tag is a number unique to the attribute. The value representation defines what type of value the attribute can have (e.g., a 64-character string, binary data, etc.).
In accordance with DICOM standards, there are three types of attributes. Type 1 comprises attributes which are mandatory and must always be present with a value; Type 2 comprises attributes which are mandatory but are allowed to be empty; and Type 3 comprises attributes which are optional and are also allowed to be empty. An incompatibility between two devices may arise, for example, if the receiving device requires that a Type 3 attribute be transmitted while the sending device does not include that attribute in its transmission. As a result, even if both devices are configured in accordance with current DICOM standards, the data transfer cannot occur. Thus, even mutual conformance to DICOM standards does not guarantee that two devices can be compatibly connected to each other.
In accordance with a further aspect of the DICOM system as currently implemented, an ultrasound imaging system can retrieve a worklist from a Radiology Information System (RIS) at a hospital via the LAN. The retrieved worklist may, e.g., comprise all patients to be examined on a particular day using that particular ultrasound imager. The worklist includes the following information for each patient: name, identification number, sex, birth date, accession number, study data, etc. The information retrieval is initiated by the ultrasound imager. In response to this query, the RIS transmits the worklist to the ultrasound imager, which stores it in memory. This worklist is then available for viewing by the sonographer. The patient currently being examined can be selected from the worklist.
In order to protect against image data loss due to a failed attempt to send image data from an imager to a remote device on a network, the user must also store that image data in a local storage device, e.g., the hard disk. These images stored in the hard disk must be manually removed at the end of the day or when the hard disk is full. This procedure has the disadvantages that the wrong images could be accidentally deleted; sorting through the images is difficult and prone to user error, which could result in the wrong images being printed; and more time between patient exams is required in order to perform manual image cleanup. In addition, if the imager""s primary storage system or printer has a failure that cannot be corrected immediately and if the imager is implemented in such a way that the image data for the failed data transfer is lost, then the result is that the patient being examined must be rescheduled and re-scanned.
Because the DICOM capability is implemented in software, these features of the ultrasound imaging system can be readily upgraded. One goal of such upgrades is to increase the efficiency of the system operator by making the system simpler to operate, e.g., by requiring fewer manipulations to activate a particular operation. Another goal of system upgrades is to increase the ability of the imager to connect rapidly, efficiently and reliably to remote devices on the network, i.e., to increase connectivity.
The present invention is incorporated in an imaging system of the type which can acquire multiple frames of images in succession in the course of a patient examination and which is capable of transferring those images to remotely located devices via a network. The computerized imaging system is programmed with software that allows properly formatted image frames (objects) to be sent to one or more remotely located devices selected from a list of activated devices. The operator interface has two or more Print/Store buttons which are configured to respective remote devices. An image frame is selected for transfer to a particular remote device by successive operation of a Freeze button and the Print/Store button configured to that remote device. In response to operation of the chosen Print/Store button, the frozen image frame is retrieved from cine memory and stored in an image file on the imager hard disk. This procedure can be repeated to print and/or store multiple image frames for each patient.
In accordance with the preferred embodiment of the invention, for each job selected for transfer to a remote device, an element is added to a linked list which forms a virtual queue (hereinafter xe2x80x9cActive Queuexe2x80x9d), each element incorporating a respective pointer (i.e., the file name) identifying each stored image to be included in that particular job. Each element identifies the image frames included in the job, the destination remote device, and additional pertinent information. The Active Queue is maintained on the hard disk. In the event of a loss of power to the imager, the information stored on the hard disk will not be lost. Retention of the Active Queue (and other linked lists described hereinafter) on the hard disk enables recall, when power is restored, of the DICOM status in effect at the time of the power loss.
The imager is programmed to attempt to transfer the queued jobs in the order in which their respective elements are listed in the Active Queue. If the attempted data transfer is unsuccessful for any reason, the element for that failed job is removed from the Active Queue and added to a second linked list which constitutes a virtual holding queue (here-inafter xe2x80x9cHolding Queuexe2x80x9d) for failed jobs. If the attempted data transfer is successful, then the successfully transferred images are automatically deleted from the hard disk. In addition, the element for this successful job is removed from the Active Queue.
In accordance with another preferred embodiment, a third linked list of elements (hereinafter xe2x80x9cPartial Print Queuexe2x80x9d) is constructed for images making up a multi-image film session. For example, if images are to be transferred to a printer which is configured to print film sessions comprising N images, then the imager will normally not send each film session until all N images have been acquired. The file name for each of the N images is added to the Image File Name field of the element representing the particular job (i.e., film session) to which the images belong, each file name being added as that image is accumulated. When the N-th image of a film session is accumulated, the element for that film session will be deleted from the Partial Print Queue and added to the Active Queue.
The preferred embodiment of the invention further comprises software for displaying, for each destination remote device, a status menu having respective fields for indicating the number of jobs in the Active Queue and in the Holding Queue, and a field for indicating the number of images frames of a multi-image film session in the Partial Print Queue, which are directed to that particular remote device. It should be understood that status menu incorporates fields which are virtual representations of the respective queues stored in memory. However, the respective queues stored in memory list elements which point to stored images or sets (film sessions) of images destined to be sent to all activated remote devices. In contrast, the status menu has first and second fields which respectively indicate the number of jobs (single image frames or multi-image film sessions) held in the Active and Holding Queues for each remote device individually. A third field is provided on the status menu for each printer configured to print multi-image film sessions for displaying the number of accumulated images in a film session.
In accordance with the preferred embodiment, the Active Queue field on the status menu is incremented by one (not by the number of images comprising the film session) for each multi-image film session element transferred from the Partial Print Queue to the Active Queue. If the attempt to transfer a job to a remote device fails, then the Holding Queue field on the status menu will be incremented by one and the Active Queue field on the status menu will be decremented by one.
The preferred embodiment further comprises software which allows the imager operator to redirect jobs held in any queue to any other activated remote device. For example, the operator can select the Active Queue field of a primary remote device, select the name of a secondary remote device, and then click on a virtual representation of a Send key on the status menu to redirect a job to the secondary device.
In a similar fashion, an incomplete film session can be queued for transfer to any activated remote device by selecting a particular Partial Print field, selecting the name of a particular remote device and then clicking on the virtual representation of the Send key on the status menu. The number of images entered in the selected Partial Print field will change automatically to zero, while the entry in the Active Queue field of the selected remote device will be incremented by one or more, depending on how many images are indicated in the Partial Print field and how many images constitute a complete job for the selected device.
In accordance with a further feature, the status screen displays a virtual representation of a Display Queue key for initiating the display of the contents of a selected queue. In response to selection of a queue field on the status menu and clicking on the Display Queue key, the imaging system will bring up a different menu showing a list of jobs waiting in the selected queue.